Ambiguity: How to handle concurrent access to the DPD cache from multiple relay threads.
Choice: DashMap<DpdKey, DpdEntry> — a lock-free concurrent hashmap.
Rationale: Avoids lock contention when multiple tokio tasks process packets concurrently. DashMap's shard-based design provides good throughput under high packet rates.
Ambiguity: Hash function for H-DPD mode.
Choice: murmur3_x64_128 with seed=0, taking lower 64 bits as packet_id.
Rationale: MurmurHash3 is fast, has good distribution, and is the de facto standard for non-cryptographic hashing in network applications. gated behind optional murmur3 dep (only pulled in with smf feature).
Spec said: DPD cache with background eviction task.
Implemented: Uses tokio::spawn for background eviction, requiring the rt feature on tokio.
Why: The eviction task runs asynchronously on the tokio runtime. Added rt to the tokio features list.
Alternatives: (A) Fixed 1-second eviction; (B) window/4 adaptive interval.
Chose B: Per RFC 6621, eviction should happen at window/4 to balance memory use against eviction overhead. For sub-second windows, the task short-circuits (no eviction needed).
The current implementation handles SMF_DPD option encode/decode at the option level. Actual insertion into the IPv6 Hop-by-Hop extension header is the caller's responsibility (requires raw socket access). A helper for this could be added in Issue #8 (Forwarding Engine).